Subject: DLSw RFC related questions

From: [email-masked] (Himanshu C. Shah)
Date: Fri, 11 Jun 93 17:28:05 EDT

Hi, 

I am coming upto speed on DLS and a new member of SIG. I am not very familiar
with SNA or NetBios but just with the bridging and may be this is a blessing
in disguise. I think the goal for DLS should not be limited to overcome
the shortcomings of SNA or NetBios but any other protocols that use 
connection oriented data link layer in a remote bridge environment. May be
this is a non-goal, if so, let me know.

I have several questions, some of which may have been discussed in the past
and is probably re-asked here with a different twist.

1) I plead ignorance here since I have not put DLS state machine under
microscope, But my general question is, Is DLS state machine capable of
handling switching following data link matrix, first as a single DLS entity
and secondly as a DLS pair over TCP. If not, we should make necessary
adjustments.

	SDLC(p)  <==> SDLC(s)
	SDLC     <==> LLC2
	LLC2     <==> LLC2

2) What does +really+ uniquely identify a single end-to-end connection 
between two end stations? 
	1) Pair of circuit IDs + Pair of Transport Ids
 or	2) Pair of circuit IDs + data link ID
 or	3) Pair of circuit IDs + Pair of Transport Ids + data link ID

I am wearing a network manager cap here who is really collecting all the
topology tables from the DLSs and want to identify/manipulate a one
entire link.
BTW, does there exist an "identifier" for a DLS which uniquely identifies
a DLS and is an IP address a part of the identifier. 

It is nice to exchange two levels of data link cookies (circuit ID) and 
transport id (a TCP session handle), but these have local significance
and not unique across the network. Only thing unique is data link ID which
I am afraid with locally-administered addresses and well known SAP usage
may not be unique (and only RIF can be a tie-breaker, oh god no!!).

3) What kind of information is cached from C-U-R message? (MACaddr, IPaddr,
transport ID, SAP(?))

How long is this information kept?

Is cache aged? (what age, what resolution), refreshed? (from what?)

4) Why is I-C-R message not considered as a candidate for broadcast?
Given the nature of client-server model in SNA, caching of information
from ICR has greater significance and will cut down a large number of 
broadcast directed CURs. 

Why is the state machine so primitive that in disconnected state if it
receives an unsolicited ICR it steps into circuit-established state?

5) Why is there no end-to-end MTU negotiation? We need  a field in
the control header which represent MTU. As we know, target DLS may try to
find the destination in a source route bridged environment where LF-bit
negotiation is important criteria for the path selection. Last thing one
wants, is to have TCP circuit established but target DLS drop the I-frames
because they are too big to go through SRBs.

6) Page 8, 2nd paragraph describes what target DLS does when CUR is received.
I think there is a whole lot of information that is missing here.

	a) How is TEST frame sent? Is it source routed? STE? ARE? To what
	SAP? (0x00, 0x04).

	b) If ARE what is the criteria for selecting the best path? First
	arrived with suitable MTU? (See (5) for lack of information on 
	what a suitable MTU is)

	c) How long does Target DLS wait before giving up on TEST response
	and get rid of the control structure?

	d) How long does source DLS wait before giving up on ICR and free
	up the resources?

7) What does source DLS do when it has multiple CUR candidates to the 
same destination MAC address and it is pending on ICR?

8) What about transparent bridging support? As we know there is no standard
for Source Route Bridging. There is a draft standard IEEE802.5M/D7 for SRT
which is now close to become a standard and will be added as an 
addendum to IEEE802.1d standard. According to this standard, a token ring
port in a bridge will support both Source route bridge as well as 
transparent bridging. If an end station uses A & C bit setting on a
transparent test frame to decide whether the destination is locally present
on the ring or not, this will present a problem for Data link Switches in SRT 
bridged LAN. In order to prevent loop through the DLS cloud, Spanning Tree
Protocol becomes a necessity. 

We must have a code point in the control header to pass Hello BPDUs around
to form a spanning tree and break the loops.

There is also another standard evolving for end stations, called 
Route Determination Entity (RDE), to select a suitable frame format in 
different bridged environment. RDE defaults to transparent bridged 
environment.

9) Page 9, 2nd paragraph, suggests NetBios control message include RIF
in the DLC header which should be padded to 18 bytes, WOW!!

Why is DLS responsible for this? Why should it be,

	a) source routing frame
and	b) a rif with 18 bytes (standard allows upto 30 byte RIF)
and	c) padded (there is no such standard where padding is required)
and	d) with all these additional work, destination DLS throws the RIF
	away anyway...

10) section 4.1.2: Link Restart Protocol. Why is 'link restart' treated as
disconnect on the data link side when there does exist a 'link reset' concept?

Is this SNA or NetBios specific characteristics? Is this good enough
reason for a general-purpose DLS goal?

Editorial: paragraph 4 in the same section. 'CONNECT' probably means 
'CONTACT'.

Stay tuned, I have more..

Himanshu